Mathematical Service Discovery

Matchmaking has been a subject of research for many years, but the increasing uptake of service-oriented computing, of which the Grid can be seen as a particular instance, has made effective and flexible matchmaking a necessity. Early approaches to matchmaking and current schemes in the Grid community, like ClassAds, take a syntactic point of view, essentially matching up literals or satisfying some simple constraints for the purpose of identifying computational resources. The increasing availability of web services shifts attention to the function of the service, but WSDL can only publish (limited) information about the signature of the operation which tells the client little about what the service actually does. The focus in the MONET (www.monet.nag.co.uk) and GENSS (genss.cs.bath.ac.uk) projects has been on describing the semantics of mathematical services and developing the means to search for suitable services given a problem description. In this paper we discuss (i) the schema extending WSDL that we call Mathematical Service Description Language (MSDL), (ii) a number of ontologies for describing various properties of mathematical services, (iii) an approach to describing preand post-conditions in OpenMath (www.openmath.org) and (iv) an extensible, generic matchmaking framework along with a suite of match plug-ins that are themselves web services. 1 Relevance to Computational Science A long term vision for computational science is the realization of a desktop environment for scientific research, where the scientist is as easily able to find data sets, the algorithms to manipulate them and the means to display them— in silico experiments — as they currently do with physical materials in the laboratory — in vivo experiments. The ability to solve large computational science by the coordinated use of distributed resources has been advocated by a number of researchers. Work in this area has primarily focused on the development of “Problem Solving Environments” (PSEs). A PSE is a complete, integrated computing environment for composing, compiling, and running applications in a specific area [10]. In many ways, a PSE is seen as a mechanism to integrate different software construction and management tools, and application specific libraries, within a particular problem domain. One can therefore have a PSE for financial markets [4], for gas turbine engines [8], etc. Focus on implementing PSEs is based on the observation that previously scientists using computational 2 Julian Padget and Omer Rana methods wrote and managed all of their own computer programs – however now computational scientists must use libraries and packages from a variety of sources, and those packages might be written in many different computer languages. Engineers and scientists now have a wide choice of computational modules and systems available, enough so that navigating this large design space has become its own challenge. A survey of 28 different PSEs by Fox, Gannon and Thomas (as part of the Grid Computing Environments WG) can be found in [9], and practical considerations in implementing PSEs can be found in Li et al. [14]. Both of these indicate that such environments generally provide “some back-end computational resources, and convenient access to their capabilities”. Furthermore, work-flow features significantly in both of these descriptions. In many cases, access to data resources is also provided in a similar way to computational ones. In [7] the authors identify how the original multiphysics problem – in this case a gas turbine engine simulation – may be considered as a set of smaller simulation problems on simple geometries that need to be solved simultaneously while satisfying a set of interface conditions. These simpler problems may be chosen to reflect the underlying structure/geometry/physics of the system to be simulated, or artificially created by scientific computing techniques such as domain decomposition. For physical systems and devices, these sub-problems are usually modelled by partial differential equations. The next step is to create a network of collaborating solver agents in which each such agent deals with one of the sub-problems defined earlier. This work therefore also can be considered as an aspect of PSEs, where a larger problem is decomposed and handed off to independent agents which can then aggregate their results. Looking at these two aspects of PSEs together, we can see the need for a “matchmaking” process, which is able to: (i) decompose a larger problem into smaller components, based on very specific domain dependent information; (ii) map each of these smaller problem components to particular solvers that can be found in a registry. The granularity of the decomposition process and the capability inherent within each problem solver provides two constraints on the usefulness of this approach. 2 Technical Background The work reported here stems from a series of projects, each focusing on different contributions to the goal of building a computational environment for scientific research: – OpenMath provides an extensible framework for the authoring of mathematical ontologies – MONET demonstrates feasibility of semantic processing from user query to service invocation [5] – GENSS generalizes the matchmaking/brokerage component [16] and extends matching to conditions and effects [18] – KNOOGLE implements an open architecture for matchmaking and brokerage [12] We will now discuss each of these and their contribution in some more detail. Mathematical Service Discovery 3